型を用いたError Handling
コンパイル時に静的検査される
「失敗するかもしれない型」を用いる
どうやって値を取り出す？
パターンマッチが必ずある？
たいてい関数型の言語？
何が嬉しい？
誤ってnull値にアクセスすることがない
コンパイルエラーでnullチェックを強制される
型を見るだけで失敗する可能性があることがわかる
TSからちゃんとプログラミングを始めたmrsekut.iconにとっては意外だったが、型を見るだけでそれがnullになりうるかどうかを判断できるのは実はすごいことなんだな
こういう型のパワーは代数的データ型の効用らしい(たぶんちょっとmrsekut.iconの解釈に語弊がある) ref Haskell
Maybe a型はJust aもしくはNothingを返す
「失敗するかもしれない」ことを表す型
code:hs
main = do
a1 <- 失敗するかもしれない処理1
a2 <- 失敗するかもしれない処理2 a1
..
のように処理を続けて行った場合どこか失敗(Nothing)になると、それから先は全てNothingになる
JustとNothingは論理和のような関係で、全体の結果が決まる
Either a b型はLeft aもしくはRight bを返す
Maybe型とほぼ同じ
失敗を表すLeft aの時に例えばLeft Stringのようにすると、エラーが起きた理由をエラーメッセージとして返すことが出来る
Maybe型もEither型もFunctor, Applicative, Monadの型クラスのインスタンスである
Scala
Option[T]型
Some[T]もしくはNoneを返す
getOrElse()を使って値を取り出す
引数はNoneの場合に返すT型のdefault value
Either[A, B]型
Left[A, B]もしくはRight[A, B]を返す
Try型
Eitherと似ているが失敗時には例外を保持する
非同期処理のtry/catchでは例外を捕捉できない
SuccessもしくはFailureを返す
Rust
Elm
Maybe, Either
Swift
Kotlin
Null Safety
型の後ろに?つけるやつ
なので↑の型のものは書かないとコンパイラに怒られる
code:kt
var s : String? = null
if(s != null) {
s.length
}
このifの中ではスマートキャストされnullableでない型にキャストされる
ここではString型
Kotlinではnon-nullに代入した箇所で動的にnullチェックされるため、引数の?を付け忘れると実行時に死ぬref コンパイル時の話？
あまり型が厳格でないのかな、わからんmrsekut.icon
TypeScript
Union型を使えば同じことができる
strict: trueにしておけばnullチェックが強制される
type A = string | null
type A = string?でも同じ、ではない
以下の様に書くことが強制される
code:ts
const s: string | null = null;
if (s != null) {
s.length; // OK
}
チェックする箇所を多少減らせる
nullチェックの記述が簡潔になる
穴もある
anyを使うとnull安全機能は局所的に無になる
そもそもunsafeな書き方ができる
tsconfigでstrict: trueにしてないとチェックをしてくれない
漸進的型付けが出来るためにanyがあるので、本来0からTypeScriptで書くならanyは一切不要、な気もする
外部ライブラリとのアレはあるが
あ、nullとundefined区別するのかmrsekut.icon*3
C#,
Java